Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request removes the A2A extension activation mechanism entirely from the specification, transitioning clients and agents to rely solely on A2A metadata for negotiating supported A2UI versions and catalogs. The review feedback points out that the Python SDK implementation still contains the legacy activation logic and needs to be updated to align with this change. Additionally, several grammatical and phrasing improvements are suggested for the documentation to enhance clarity and correctness.
|
|
||
| ### 2.6. Agent card and transport metadata | ||
|
|
||
| - Removed the A2A extension activation mechanism entirely. Clients and agents now rely purely on A2A metadata to negotiate supported A2UI version and catalogs. |
There was a problem hiding this comment.
Grammar/phrasing suggestion: "negotiate supported A2UI version and catalogs" should be "negotiate the supported A2UI version and catalogs" or "negotiate supported A2UI versions and catalogs" for proper parallel structure and article usage.
| } | ||
| } | ||
| ``` | ||
| A2UI does not use A2A extension activation. Clients advertise the supported A2UI version and catalogs by attaching `message.metadata['a2uiClientCapabilities']` to their messages. Agents use A2UI by sending payloads with `DataPart.data.metadata['mimeType'] = 'application/a2ui+json'` to clients. |
There was a problem hiding this comment.
Nit: Maybe we can explicitly mention that the developer simply sets the version-specific client capabilities submessages to indicate which protocol versions are available. E.g.
{
"v0.9" : { "supportedCatalogIds": [ ... ]}
}
3 participants
We made extension activation optional previously as nobody was using it and we didn't need it.
For 1.0 we explicitly remove it.